COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	nolook[e83,jmc]		Modifying programs without looking at them
C00008 ENDMK
C⊗;
nolook[e83,jmc]		Modifying programs without looking at them

	Our goal is a programming language in which we can write
programs that can often be modified without looking at them.
We won't always win; sometimes we'll have to understand the program
before we change it.
The goal is to be realized by using a language for describing modifications
to programs.  This
may seem impossible, but consider the example of the boss of an
airline who wants the reservation program modified.  He says to
his underlings,

	%2"Modify the reservation program so that it never seats
an Iraqi next to a seat already assigned to an Iranian and vice versa"%1.

	The boss doesn't have to know anything much about the reservation
program to give this command.  Why should the underlings have to know
much about the program in order to pass the command on to the computer?
Actually we suppose the information is given to a generalized
compiler that takes a source program and a proposed modification.

	Notice the following:

	The boss assumes a certain amount of real world knowledge.
His underlings know what are Iraqis and Iranians.  They also share
with their boss terminology concerning the assignment of seats and
know the adverb "already".  Thus they know about events taking place
in time.  It seems unlikely that the compiler could know how to modify
the program unless it also had a certain amount of real world common
sense knowledge.

	Therefore, the source program must contain a connection between
real world concepts like %2seat assignment%1 and whatever data
structures represent the seat assignment internally.  Actually,
it seems even better if the source program does not mention any
data structures.  In the case of an airline reservation program
it should work in terms of events rather than in terms of data
structures.  We need a formal parallel to the English definition:

	%2A passenger has a seat assigned to him if the assignment been made
and not subsequently cancelled%1.

	The conditions for assigning as seat must refer to the assignments
that exist.  It is up to the compiler to figure out how to compute these
conditions.  It will presumably decide to do this by remembering the
assignments in a suitable data structure.  However, we can imagine
the assigment being recorded outside the computer.  For example, the
passenger might place his name card on the seat and the reservation
program might look each time.  Alternately, the passengers might
be members of an organization whose travel needs could be computed
from some other files.  We don't advocate such solutions;
we only want to liberate the imagination and separate the concept of
a fact on which the program takes action from any concept of how
the fact is represented in the memory of a computer.

	Because the notion of seat assignment is defined in the
external language and is known to the boss of the airline and
his employees, he can command a change in the conditions for assigning seats.
If this external language is used to write the source program,
anyone who knows the language can propose a change.

	We can propose a change all right, but clearly it will take
a very clever compiler to implement changes described in this way.
Moreover, we must formalize the fragment of common sense language
used to describe programs and modifications to them.